As the client and server were implemented at the same time, the client was not available for use in order to test the server. Instead, server testing was done initially through the use of a Telnet\footnote[9]{\url{http://telnet.org} \indent\newline(Accessed: March 2012)} client along with test scripts -- simply text files containing a number of messages to be sent to the server, as well as by entering arbitrary test data as required. Telnet allows a connection to be made to any arbitrary address and port, allowing text to be sent and received via this connection. These test scripts were then passed into the Telnet client which would then send those messages to the server, allowing us to see the responses from the server as they are received. This was preferable to unit testing as it saved a large amount of time – something that was restricted -- and gave a more ``hands-on'' approach to testing. The test scripts are attached within appendix D1.

Initial tests via this method proved that the design of the server network components was solid in terms of ease of debugging -- any error that occurred in terms of message processing could easily be traced back to the particular concrete message class rather than spread over several locations in the codebase. This testing phase showed that the server operated correctly, already capable of supporting a number of clients at once as well as processing and sending all messages correctly. The only major problem identified during this test phase was that a user could not log back in after closing the connection before logging out. This was due to a flaw in the section of the client controller that handles heartbeat requests; the ``heartbeat detected'' state was not being reset properly following a heartbeat request and thus it seemed that the client was always logged in.

Using unit tests to simulate a client would have provided a more exhaustive testing method. This method would also have been more structured and automated, than the method described above. In addition, it would have meant that we were not reliant on the client to test the server comprehensively. 
